\begin{figure*}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{SecurityRules.png}}	
	\caption{Security Rules}
	\label{fig:rules}
\end{figure*}

\subsection{Static Mapping (SM)}
\label{sec:StaticRules}
Security policies are defined on the abstract level on roles, actions and contexts. To link these concepts to the target application, we consider two types of mappings, namely static and dynamic mappings. Static Mappings declare relationships between the policy (role and actions) and the applications concepts (classes and methods). This allows a better flexibility: working at the metamodel level makes these mappings clearer than spreading these relations directly within the Java code.

A \texttt{StaticMapping} is either a \texttt{RoleDeclaration} or an \texttt{Action\-Dec\-la\-ration}. A \texttt{RoleDeclaration} binds a policy \texttt{role} to an application \texttt{class} of the application: this way, each instance of this \texttt{Class} is treated as a subject of this \texttt{Role}. A optional list of \texttt{Field}s can be attached for performance purposes: only the relevant instance fields will be monitored. An \texttt{ActionDeclaration} binds a policy \texttt{action} to a sequence of methods in the application. To ease further reference, methods can be aliased to simpler names, bound in the order of the methods sequence.

Below are examples of static mappings, in a textual concrete syntax. On the left, the \texttt{RoleDeclaration} binds the role \textsf{doctor} to the class \textsf{Doctor}, asking the \textsc{Pep} to monitor the (instance) field \textsf{patient\_name}. To avoid confusions, class names are fully qualified, and fields' types are repeated to open for well-formedness rules consistency checks in other parts of the \textsc{Dsl}. On the right, the \texttt{ActionDeclaration} binds the action \textsf{delete} to a sequence of two methods named \textsf{deleteFile} in classes \texttt{Service} and \texttt{DB}, respectively. Then, \textsf{deleteService} and \textsf{deleteDB} are aliased to these methods. Again, methods are fully qualified and declared with their signature to avoid confusion in the presence of method overloading (cf. \cite[Sec. 8.4]{B:Gosling-etAl}). 

\bigskip\noindent
\begin{minipage}{\columnwidth}
	\begin{boxedminipage}[t]{0.51\textwidth}
		\begin{tiny}
			\begin{sffamily}
\textbf{role} doctor\\
\textbf{class} \texttt{com.*.Person.Doctor}\\
\textbf{attributes} \texttt{ArrayList<String>: patient\_names}
			\end{sffamily}
		\end{tiny}	
	\end{boxedminipage}
	\hfill
	\begin{boxedminipage}[t]{0.48\columnwidth}
		\begin{tiny}
			\begin{sffamily}
\textbf{action} delete\\
\textbf{methodId} deleteService, deleteDB\\
\textbf{sig} \texttt{*.Service.deleteFile(int, String, int)\\
 \phantom{MMM} -> *.DB.deleteFile(File)}
			\end{sffamily}
		\end{tiny}
	\end{boxedminipage}
\end{minipage}
